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Abstract — Group management is a fundamental building 
block of today's Internet applications. Mailing lists, chat 
systems, collaborative document edition but also online social 
networks such as Facebook and Twitter use group management 
systems. In many cases, group security is required in the sense 
that access to data is restricted to group members only. Some 
applications also require privacy by keeping group members 
anonymous and unlinkable. Group management systems rou- 
tinely rely on a central authority that manages and controls 
the infrastructure and data of the system. Personal user data 
related to groups then becomes de facto accessible to the central 
authority. 

In this paper, we propose a completely distributed approach 
for group management based on distributed hash tables. As 
there is no enrollment to a central authority, the created 
groups can be leveraged by various applications. Following 
this paradigm we describe a protocol for such a system. We 
consider security and privacy issues inherently introduced 
by removing the central authority and provide a formal 
validation of security properties of the system using AVISPA. 
We demonstrate the feasibility of this protocol by implementing 
a prototype running on top of Vuze's DHT. 

I. Introduction 

Recent years witnessed a rapid growth of Online Social 
Networks (OSN) sites. OSNs allow communication with 
social acquaintances or with users having similar interests. 
The notion of group, also referred to as social order is 
a fairly natural way to sort interactions in our daily social 
life ilTll . Many of today's Internet applications can be 
considered as group management systems: OSN but also 
mailing lists, chat systems or collaborative document edition 
systems. 

From a security and privacy perspective, it is desirable that 
group information, such as the exchanged messages but also 
the group member list, is not accessible to anyone outside 
the group. However, group management systems often rely 
on a central authority that manages and controls the system's 
infrastructure and data. Thus, personal user information 
used during group communication, such as acquaintances, 
political views and photos, become accessible to the central 
authority. We believe that an interesting research direction 
is to give users back control of this data. 

Other drawbacks of group management systems with 
centralized authority may be mentioned: (i) The scalability 
of the system depends on the capacity of the central authority 
to dimension the infrastructure resources according to the 



load, (ii) Sharing or reusing groups from one application 
to another is difficult, as many group management systems 
define their own proprietary solution and infrastructure. Yet, 
a group of users subscribed to a VoD service should be able 
to anonymously contribute to movie reviews on a partner 
movie site. (Hi) Bootstrapping new group communication 
applications requires deployment of a new dedicated infras- 
tructure and system. Therefore, there is a need for a generic 
and reusable group management mechanism that could be 
leveraged by various applications dealing with groups. 

While contributions have been made for some of the 
previous problems regarding privacy concerns jsl S or 
regarding scalability issues 120(1 . none of these approaches 
is able to resolve all above concerns. In addition, a central 
authority has low interest in deploying privacy preserving 
solutions such as jsHstl- Therefore, and similarly to Diaspora 
1 1311 . a development project for a distributed OSN (see 
Section IVB . we believe that only a distributed system with 
no central authority is able to resolve all of the above issues. 
In such a system the infrastructure is typically composed of a 
set of end-user devices, which we call nodes, running a piece 
of software and providing spare storage and CPU resources 
to the system. 

With a distributed system as described before, we must 
assume that some participating nodes have been compro- 
mised and are under the control of an adversary. No central 
authority can guarantee that the devices running system 
nodes are honest. In such a context, we are thus interested 
in building a distributed group management system with 
fair security and privacy properties against participating 
nodes. Whisper |23| has similar objectives and specifi- 
cally focuses on confidential communication within formed 
groups. Whisper achieves them by combining gossip-based 
communication protocols and onion routing. In this paper, 
we focus on a broader set of services that allow building 
a complete group management system. On the security 
side. Whisper considers a threat model where nodes fully 
comply with the specified protocol but try to passively 
eavesdrop member and group information or any other type 
of message not meant to be read by this particular node. 
Whilst we consider the same threat model regarding privacy 
prop erties, we extend the model to a Dolev-Yao adversary 
il4ll regarding security properties and formally validate our 
security objectives against the latter attacker 



Contributions: we propose a completely distributed ap- 
proach for group management requiring no central authority, 
based on Distributed Hash Tables (DHTs). The proposed 
system is generic and may be leveraged by various applica- 
tions that need group management. 

The system offers a set of security properties against 
adversaries that compromised nodes of the system. This 
includes confidentiality and integrity of group information 
against a Dolev-Yao adversary lll4ll . In addition the system 
enables user anonymity and ensures that users belonging to 
two different groups stay unlinkable, in particular against 
nodes of the DHT that comply with the protocol specifica- 
tion but try to passively steal information of other partic- 
ipants or groups. If required by group policy, anonymous 
communication between group members is also possible. 

We provide a formal validation of security properties 
of the protocol using AVISPA fill and discuss to what 
extent the proposed system meets the privacy objectives. 
The proposed system does not try to address attacks on the 
system availability, such as Byzantine failures. Instead, we 
refer to the recent advances in this field ll26ll . We however 
address the specific security and privacy problems that have 
been introduced by removing the central authority and by 
moving to a completely distributed architecture. 

Finally, we prototyped our protocol on top of the 
Vuze DHT. While limitations remain because of the non- 
optimized Vuze DHT, we show that distributed and private 
group management is feasible with acceptable performances. 

The remainder of this paper is structured as follows. Sec- 
tion HI] introduces the proposed group management system 
with no security. We then present in Section |lll] our security 
objectives and considered adversaries, the cryptographic 
means and security protocol used. In Section |IV] we analyze 
the security and privacy properties of the system. We then 
present in Section [V] a prototype of our system, and the 
results of a 2.5 day execution. Related work is presented in 
Section |VT] Finally we conclude with Section IVIII 

II. A DISTRIBUTED GROUP MANAGEMENT SYSTEM 
A. Motivating example 

We propose collaborative document edition as an exam- 
ple that motivates the needs of a social-based and secure 
application. Collaborative document edition is an example 
where users want visible actions to be restricted to a trusted 
group of people; however, the decentralized location of the 
edited document is also of interest for privacy, as opposed 
to storage at a single service provider 

Our group management system allows the creation of a 
group dedicated to specific documents. Then it allows the 
control of who should be able to join the group of people 
editing the document. The group(s) administrator(s) grants 
access to a user Depending on the document policy editions 
could be performed anonymously. It is also possible to hide 
which pseudonym made the modifications. Modifications are 
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Figure 1. High level view of our group management system: multiple 
applications are accessing groups managed by users. Groups are mapped 
to random DHT locations, and are hosted on commodity hardware. 



saved and accessible on nodes participating to the group 
management system, in a distributed fashion, thus potentially 
allowing a large number of users to edit the same document. 
Users that are banned from the group of editors, users that 
decided to leave, or any other non group member, are not 
able to perform editions, nor to read the document. 

B. System schematic 

A distributed hash table is a well known tool when it 
comes to decentralized and scalable 1 to 1 communication. It 
exports a basic interface providing PUT and GET operations, 
allowing to map < key, value > pairs to nodes participating 
in the system. This is done by hashing an object's content, 
in order to obtain a random address on the DHT's address 
space (typically of size 160 bits, as e.g. in the Vuze's DHT). 
Nodes are themselves responsible for a subset of this space, 
based on their position in the DHT (depending on their ID 
in the same address space). 

In this paper, we assume a Byzantine Fault Tolerant DHT 
for building our system. Indeed, recent advances make DHTs 
tolerant to Byzantine adversaries, while conserving loga- 
rithmic cost of operation in expectation 12^. Basic storage 
systems on top of DHTs 12211 can also implement Byzantine 
fault tolerant replication in relatively stable environments, 
using mechanisms providing eventual consistency ||24ll. Nev- 
ertheless, handling both dynamicity and BFT nodes is still 
under research 171]. 

We design our group management system around a group 
structure. This abstraction, composed of a root, a member 
list, a wall and an inbox, allows the representation of com- 
plex objects and interactions. A user that joins the system 
can create principals. We consider a principal as an instance 
of a group structure, the list being for instance in the context 
of OSNs filled with friends, and the wall by messages for this 
given principal; the inbox receiving system or user messages. 



Users can also create and manage groups, which contain 
other users, groups and objects. Belonging to a group, thus 
being a member, means being able to access objects of that 
group and interact with other group members, depending on 
the defined groups privacy and security policy. Users create 
principals to join with groups, possibly one new principal 
for each joined group. Group creators can create and destroy 
groups and define the join policy and the visibility policy 
of the group, as illustrated in Table U Administrators handle 
join and leave requests. The great flexibility regarding the 
join policy and the visibility enables very different types of 
applications to run on top of the system. The roles creator, 
administrator and member depend on the knowledge of 
cryptographic keys described in Section UlI-BI 

On an implementation level, the root is the entry point 
of a group structure; it is a file containing metadata about 
group's attributes, and pointers to list and wall. The list 
references principals and groups that are members of the 
current group. The inbox is a list of messages, typically 
join request from principals. Finally, the wall is to be seen 
as a space containing raw data as objects (if their size is 
small) or references to objects, and system messages. On the 
distributed side, each element of a group structure, as well 
as nodes' inbox, is hosted on a random DHT node (and then 
replicated on node's neighbors for reliability 12211 '). Figure [U 
presents a high level view of the system, with applications 
leveraging groups of users. 

This system is made available to programmers through 
an API, providing basic operations to create, manage, join, 
leave, list members of a group, or to send a message to a 
given principal or to the whole group for instance. 

C. Benefits and properties 

As opposed to the design of an access management for a 
particular application, the purpose of abstracting the notion 
of group as a general system-core entity is to provide means 
of genericity, reusability and applicability. Our group man- 
agement system is generic in the sense that the operations it 
provides are general yet powerful enough to be leveraged by 
multiple social-based applications. When a group is formed 
in our system, it can be accessed by different applications, 
providing reusability. In other words, a group instance can 
be used by multiple applications at runtime, without the need 
for those applications to collaborate or to be aware of their 
respective existence. Finally, applicability comes from the 
fact that our system can be run on commodity hardware, 
avoiding the need for investment in a server farm or rental 
of a specific cloud service. As it is by nature distributed, it 
can be hosted on user machines, along with the application 
that is using it. Finally, relying on a DHT and distributing 
responsibilities to random nodes allows our system to be 
scalable in the number of users and in the number of groups. 
Scalability in the number of users per group can however be 
an issue for very large groups, as nodes hosting structures 



may be contacted frequently. However, studies IitIi reveal 
that group sizes are following a power-law distribution, with 
a vast majority of groups containing only few members. 
For very large groups, we do not claim to provide better 
scalability than traditional distributed applications as for 
instance publish/subscribe systems, also relying on master 
nodes in DHTs ifTlll . 



III. Security protocol 

A. Security and privacy objectives 

In this work we focus on the attacks that become possible 
because of the distributed nature of our group management 
system: some nodes providing storage and CPU resources 
could be under the control of an adversary. Attacks leading 
to user profiling and De-anonymization la 12511 have been 



demonstrated against deployed OSNs. These attacks rely on 
publicly available group member lists. Our system does not 
claim additional resistance to such attacks for groups with 
publicly available member lists. 

Our sec urity objectives are relative to the Dolev-Yao (DY) 
adversary 11411 . The DY adversary fully controls the network 
and some nodes but can not reverse any cryptographic 
operation. Our security objectives are: 

• Ensure the confidentiality of private and secret keys, 
see table HH 

• Ensure the access to public keys according to group 
policy. 

• Ensure access control to group information (wall, list, 
membership) according to group policy. 

• Ensure the integrity of messages sent by participants. 

• Ensure the security of the capture and update mecha- 
nism (see IIII-BT i. 

Regarding availability, the present work does not address 
Byzantine failures. We refer to the recent advances in this 
field lE6ll . We however discuss the risk of an adversary 
flooding the DHT or squatting addressed. 

The privacy objectives listed below are relative to an 
adversary that adheres to the protocol but uses information 
from controlled nodes and observed messages to gain addi- 
tional information. Following the terminology of Pfitzman 
et al. ifigll . the privacy objectives are: 

• Members anonymity: the adversary can not retrieve the 
identity of a group member 

• Senders anonymity: the adversary can not retrieve the 
sender of a private message. 

• Unlinkability with IP address: the adversary can not 
associate group members with IP addresses, and thus 
use the IP address as an identifier 

• Members unlinkability: the adversary shall not link two 
identities in the system. In particular he shall not infer 
that a principal is member of two different groups. 

' Note that the DY adversary is not used here as he succeeds in blocking 
any protocol. 
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Table I 

Levels of group join policy and list visibility, and examples of application. 



Our system does not provide unobservability. An adversary 
may infer group information like estimating cardinality or 
the frequency of actions. However we discuss how a suffi- 
ciently large DHT together with the PUT/GET mechanism 
could complicate the observability. Note that there exist 
obvious limitations to the above privacy objectives: trivial 
anonymity sets, principals explicitly revealing identities, etc. 
We do not address those issues in the present work. 

B. Cryptographic means 

A set of mechanisms allows achieving the security and 
privacy objectives described in the previous section. First, 
the usage of cryptographically generated address (CGA) 
ifisi 01 on the DHT ensures that only the owner of a 
given public private key pair is able to control the cal- 
culated address. Second, each node of the DHT verifies 
the signatures of data stored at an address that the node 
currently hosts. The nodes deny updates if the data is not 
signed with the private key used by the CGA mechanism. 
We call this mechanism the secure address capture and 
a secure update mechanism. Finally, users of the group 
communication system do not need to run individual nodes. 
Instead, the users use PUT and GET operations to write 
and retrieve data at specific addresses in the DHT. Thus, 
users never communicate directly with each other, which 
allows keeping them anonymous. This concept is similar to 
the usage of post-office boxes in the postal system. 

All data structures have a set of cryptographic keys. 
Public -private key pairs ensure the structure's integrity 
and are used to distribute write permissions to the users. 
Symmetric keys ensure the structure's confidentiality and 
are used to distribute read permissions to the users. The 
cryptographically generated address (CGA) is calculated 
using a hash function, noted h{) hereafter, on the structure's 
public key. Cryptographically generated addresses ensure 
that only the owner of a given public private key pair is 
able to control the calculated address. 

All structures of type root, list and wall are self- 
signed using the structure's public and private key pair 
K,K~^. In order to allow verification of the signatures by 
the storing nodes themselves and by anyone retrieving the 
structure, the public key K is also stored in clear-text at the 
structure's storage address h{K). Each self-signed structure 
has a counter c that is incremented at each update to prevent 



replay attacks. 

The address capture is successful when the storing node 
verifies that the address is empty and c = 0. The update is 
successful when the storing node verifies that the address is 
not empty and the signing key is unchanged and the counter 
is correctly incrementecQ. 

The inbox structure is not self signed as a whole and not 
subject to the capture and update mechanism. This allows 
anyone writing into the inbox. However each message is 
self-signed using the sender's keys. In order to preserve 
the senders anonymity against the storing node, the sender's 
public key is encrypted within the sent message using the 
receiver's public key (see Section UlI-CI ). 

Table HI] gives an overview of the different keys and 
addresses used by the system. The root structure is not 
encrypted. Thus, any user knowing the public key A',, or the 
address h{Kr) is able to retrieve the root structure. However, 
the root structure's integrity and write protection is ensured 
by the public private key pair Kr, K^^. K,. is stored in clear- 
text at the address h{Kr), which allows nodes and users to 
verify the integrity and correct location of the structure. The 
member list is encrypted with a key Si and signed by the 
key Kj^^. Any user having the key Kj^^ and Si can update 
the list. Any user having the key Si can read the member 
list. Similarly to the root structure, Ki is stored in clear-text 
at the address h{Ki). The wall is encrypted with key Sw 
and signed by the key K^^. Anyone knowing Sw can read 
the data on the wall. Anyone having if^^ and S^ can write 
on the wall. is stored in clear-text at the address h{K^). 
Finally, the inbox is not protected in integrity. However each 
stored message in the inbox is encrypted with the public key 
Ki of the inbox. In addition, the sender of a message also 
signs the message with its private key. 

Table HU] summarizes keys required for each the roles 
introduced in Section HI] Members receive keys for a given 
group according to the group policy. 

C. Protocols 

We describe the main protocols of our system using the 
common Alice & Bob notation. In this notation the statement 
"x sends the message m to y" is denoted x ^ y : m. 
To denote a message m encrypted by a key K we note 

^The increment is modulo the width of the counter, a long integer in our 
implementation. 
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Group structures cryptographic means. 



{m}/f. To denote a message m signed by a key K^^, 
we use the compact form {m}j^-i instead of the longer 
■m.{h{m)} x-i . This hides the construction for existential 
unforgeability. This also stresses that the signature does not 
protect confidentiality. We note x —>■ dht{a) : m when 
X performs the operation PUT{a,m) over the DHT. We 
note dht{a) x : m when x performs the operation 
TO = GET{a) from the DHT. We denote a Hst as [, ]. Finally 
we use a.h for the concatenation of a and h. 

Using this notation the general form of the capture mech- 
anism is: 

X dht{h{K)) : {type.c.K.payload}K-i. 

The strings root, list, once, wall, helo, name and 
join denote message types. 

1) Creating a group: Creating a group mainly consists 
of capturing the DHT addresses for components (root, 
list, wall) and publishing the group name in a direc- 
tory. First the group creator generates a set of keys: 
{K- \Kr),{Kr\ lu ) , ( AV 1 , Ki\ {R- \K^),Si,S^ and 
plays the group creation protocol as follows: 

g dht{h{Kr)) : {{root.Cr.i^r-A'i}^-i}^-i (1) 

g ^ dht{h{Ki)) : {list.Q. (2) 

g dht{h{K^)) : {wall.c^.{[]}5„.is:„}^-i (3) 

g ^ dht(h(K,.Q)) : {once.{Q}^-i}K, (4) 

g directory : {naiB.e.Kr}j^-^ (5) 

Messages (1) (2) (3) set-up the data structure for the group 
Message (4) stores a signed and encrypted version of the list 
counter q at the address h{Ki.Q). This counter is used as an 
anti-replay protection for join requests as shown in the join 
protocol below. We choose the address h{Ki.O) because it 
depends from Ki and because it does not override the inbox 
h{Ki). Message (5) publishes the group name in a directory. 

2) Creating a principal: As indicated in Section [III a 
principal is a group possibly with no wall and no member 
list. A principal willing to remain anonymous will not 
publish the public key of her inbox and not publish any 
information into a directory. First the user generates a set of 
keys: Kp^,Kp. 

p — > dht{h{Kp)) : {root._?Cp}^-i 



3} Joining a group: This is the most important operation 
in our group management system. First the principal gen- 
erates key pair Kj^^Kj. h[Kj) is an inbox for receiving 
messages from the administrator. In our example, h{Kj) is 
also used for receiving messages from other group members. 
Note that other applications may use two different inboxes 
here. 

Then the operation has three main stages. 

• The principal puts a join request. 

directory — > p : {■D.BS^e.Kr} (1) 

dht(h{Kr)) p '■ {{lCOOt,.Cr.Kr.Ki\ (2) 

dht{h{K,.Q)) ^ p : {once.{Q}^-i}K, (3) 
p — >■ dht{h{Ki)) : {{{join.ifp.ifj.jonce. 

{ci}k;^}k,}k-^}kt^}k, (4) 

• An administrator a gets and processes the join request. 

dht(h{Ki)) — > a : {{{jo±n.Kp.Kj.{once. 

{ci}k-'}ki}k-'}k-'}k^ (5) 

I P J 

dht{h{Ki)) ^ a : {list.ci.{[X]}s,.Ki}j,-i (6) 
a dht{h{Ki.Q)) : {once.{Q + (7) 

a ^ dht{h{Ki)) : {list.Q + l.{[X, {Kp,Kj)]]s,. 

Ki}^-..Ki (8) 
a dht{h{Kj)) : {{lielo.[/ceys]}^-i}if^. (9) 

• The principal retrieves the group information. 

dht{h{Kj)) ^ p : {{helo.[keys]}j^-i}K, (10) 

The counter c/ is used in messages (3) and (7) to prevent 
replay attacks. It is signed and encrypted by administrators 
and used as a ticket in a join request. Upon processing the 
join request an administrator checks that the counter value 
corresponds to the counter value of the list (in fact, strict 
equality is not required, it is sufficient that the counter is 
greater or equal than the current list counter). 

In message (6), [X] is the current list of members. The 
administrator sends message (8) for adding Kp in the list 
and update the counter accordingly. 

In message (9) and (10) the value of [fceys] depends on 
the group policy. The minimum is [] for a totally private 
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group, typically for subscriptions to catalogs (see Table 
The maximum is the full list of keys for a totally open group. 
For the example of Section Hl-AI the key list is [Sw^K^^^]. 
This lets anyone read/write the wall and keeps the user list 
private. 

4) Taking actions in the group: After joining a group, a 
principal may enjoy group activities. In our example a princi- 
pal will anonymously contribute to the shared document. We 
show the protocol exchange to do so in a minimalist model 
of a shared document (that just allows read and replace). 

dht{h{Ky,)) p : {wall.c^ .{[old]} -K^a} j^-i 

p dht{h{Kw)) : {wall.c^ + l.{[new]}s^.-K^}j^-i 

5) Public communications: Anyone knowing h{Ki) may 
write a message in the corresponding inbox. 

p — i- dht{h{Ki)) : mess.message 

Such communication can not be avoided in environments 
with no central authority. Optimistically this is an opportu- 
nity to contact principals that publish their address h{Ki). 
Pessimistically this is spam. Note that in our motivating 
example h{Ki) is never disclosed nor a fortiori Ki, thus 
limiting the risk of spam. 

6) Private communications: Our system allows private 
communications within users of a group. According to the 
group policy, members may learn the inbox key Ki of other 
members directly from the member list, or through trusted 
external channels like direct communication between people. 
A private communication is thus systematically encrypted 
using the key Ki, which makes it fundamentally different 
from an open communication. 

p — > dht{h{Ki)) : {{mess.message] j^-i} Ki 

In addition, a known mechanism can be used for hiding 
the IP address of the sender p to several adversary nodes. 
We provide here an example of such mechanism, directly 
adapted from Crowds 12111 . a and [3 are random addresses, 
messages (2) is sent with probability pj > 1/2 message (3) 
is sent otherwise and terminates the protocol. 

p — !■ dhtia) : h{Ki) .{{mess.message} j^-i} Xi (1) 
dht(a) — !• dht{P) : h{Ki).{{mess.message}j^-i}Ki (2) 
dht{a) -7- h{Ki) : {{mess.message}j^-i}Ki (3) 



7) Key renewal: An administrator can decide to renew 
keys such as S^- The reason for a key renewal may be the 
banishment of a group member The administrator sends the 
new keys to the inbox of each group member except the 
banned member. This is possible because the administrator 
knows the list of members and their inboxes Kj . Other more 
complex cases have to be considered such as cases where 
the administrator cannot directly address the group members 
(e.g. members haven't revealed their Kj). Further work will 
investigate the key renewal mechanisms in such cases. 

IV. Security and Privacy Considerations 

As such the proposed system is a system without au- 
thentication. Any user may create its groups and prin- 
cipals and associated keys. No central authority and in 
particular no public key infrastructure (PKI) is required, 
which makes the system scalable. Another advantage is 
that anyone can participate by creating it's principals and 
groups. Fundamentally, this is not different from services 
such as Wikipedia where anyone may sign in and contribute 
without authenticating, or webmail services such as Hotmail 
or Yahoo Mail, where anyone can create as many accounts 
as he wants without authenticating. The disadvantages of 
such systems are that it is possible to squat certain addresses 
or to flood the address space. As discussed in Section 
the address space of a DHT is typically 2^^°. We consider 
that an exhaustive flooding of the entire address space of 
the system is prohibitive. This cost of flooding may also be 
increased using cornputational puzzles, in a fully distributed 
and scalable way [|1Q] . In addition the usage of CGAs and 
the address capture mechanism (see Section Ull-Bb reduces 
the risk for an adversary to squat a particular address in 
the DHT. Finally, distributed systems with no authentication 
are su bject to Sybil attacks 11211 and solutions such Sybil- 
Guard 12711 deal with this attack. Sybil attacks are out of 
scope of the present work. 

It is also worth noting that the apphcation plugged on top 
of our group management system may implement its own 
authentication mechanism, based e.g. on PKIs, mail-address 
checking or captchas, thus controlling the users accessing 
the underlying system. 

A. Security analysis 

We first verify the capture and update mechanism. More 
precisely we verify that a DY adversary is not able to update 
a captured address, unless she captured it herself. Within the 



AVISPA framework 111], we provide a formal specification 
of the capture mechanism as well as security goal for the 
weak authentication of the entity that captures the addres^. 

The simulation shows that the unpredictability of the 
captured addresses is critical. If the DY adversary does not 
know a public key prior to the capture of the corresponding 
address, no attack is found. Otherwise, for instance if 
the adversary knows a key Ki, the attack bellow exists 
(messages (1) to (5)). The adversary i turns a predicted 
address into an inbox, so that it accepts any further message 
without verification: 

i — > dht{h{Ki)) : mess. message (1) 

The group captures (2) and uses (3) (4) the predicted address 
without noticing any difference: 

g ^ dht{h{Ki)) : {llst.Q.{[]}srKi}K^^ (2) 
g ^ dht{h{Ki)) : {list.l.{[pi]}s,.i^J;^-i (3) 
g ^ dht{h{Ki)) : {llst.2.{[pi,p2]}s,-Ki}j,-i (4) 

The adversary i{g) pretending to be g replays one former 
message that will be accepted without signature and without 
increment verification. Here, the effect is the unauthorized 
removal of the principal p2 from a group: 

i{g) ^ dht{h{Ki)) : {list.l.{bi]}5,.^Ci},^-i (5) 

We also model the protocol for creating a group, then 
creating a principal, and then joining the group (see the 
second portion of code in the appendix). We assume a 
secure channel between the group creator and the future 
administrators. This channel is used for transferring the keys 
{Kf^,Ki),Sk,iK^^,Ki). The assumption is reasonable 
when an administrator is the group creator itself, or when a 
secret is shared (which we have modeled in the simulation). 
It is also possible that a creator and some administrator 
belong to a same private group. 

We systematically verified the secrecy of the private keys 
and the symmetric keys against two different kinds of DY 
adversaries. They both control the messages send over the 
network. The first controls all the addresses from the DHT 
The second controls all addresses except those involved in 
the management of the group and the principal; note that 
this adversary still controls all inbox addresses as well as 
addresses of type once. 

For private groups, as the group in our toy example 
Section III-AI we obtain the secrecy of the group key Ki 
against the two types of adversaries. We obtain the secrecy 
of the keys of the principal Ki and Kp against the second 
type of adversary. 

^^The AVISPA code is included in appendix. 



B. Privacy discussion 

We now discuss to which extent our protocol meets the 
privacy objectives discussed in Section ITlI- Al with an adver- 
sary that adheres to the protocol but uses information from 
controlled nodes and observed messages to gain additional 
information. 

Some of the privacy objectives are achieved thanks to 
the confidentiality of information. Member anonymity would 
be broken if the adversary retrieved the public keys Ki or 
Kp from group member lists, walls or inboxes. However, 
these structures are encrypted and only accessible to the 
group members or group administrators. Thus, a single node 
storing a member list, an inbox, a wall or an inbox may 
not read these structures. Similarly, the sender anonymity 
of a private message would be broken if the adversary 
retrieved the public keys Ki or Kp from an inbox. The 
sender anonymity is preserved as each inbox private message 
is systematically encrypted with the receivers public key. 

Member unlinkability also reduces to a confidentiality 
property. As a storing node does not know the member list 
it is impossible to link its members. Only other members of 
the same two groups would be able to link. A determined 
enough adversary may try to enroll in many groups until she 
links some principals. To protect against the later attack a 
user may create different principal for different groups that 
he joins. A user may also renounce unlinkability for some 
principals that are enrolled in non-critical groups. 

Only a very costly attack may break member unlinkability. 
The attack supposes that the adversary can observe the entire 
address space at a time (which is equivalent to a central 
authority). When an administrator just added a joining 
principal to the group he updates the list structure and sends 
a message helo to the principals inbox. The adversary 
may observe these two structures updates occurring at ap- 
proximately the same time, and thus infer that the principal 
of the inbox just joined the updated group. Repeating this 
same attack for a second group would then allow linking 
the two members. This attack only reveals the principal's 
inbox address and not its public key. Therefore it does not 
break member anonymity nor sender anonymity. In addition 
the attack is extremely costly as it requires to continuously 
monitor an address space of size 2^^*^. We therefore consider 
this attack as unrealistic for our system. 

Finally, unlinkability with IP addresses is achieved by 
randomly choosing other nodes as proxies as shown in 
Section IIII-CI From an adversary node perspective it is thus 
impossible to decide for a given message if the sender's IP 
address is the actual address of the sender 

V. Prototype 

We have implemented a prototype of our protocol as a 
proof of concept, with interfacing capabilities with the Vuze 
DHT. The goal of this section is to show that ( i) our protocol 
can be operated on top of a large scale deployed and possibly 
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Figure 2. Scenario considered in our experiments. 



unmodified distributed storage infrastructure, and that (ii) 
performances can be acceptable even in an extreme case of 
leveraging a DHT implemented for totally other (best effort) 
purposes. 

A. Settings and challenges 

In order to operate a prototype in a real world setting, 
we chose to build on Vuze (previously Azureus), a well 
known BitTorrent client that includes a DHT (based on 
Kademlia) to avoid relying only on centralized trackers 
for file distribution. Vuze has been adopted all around 
the world, and its DHT is run by around 1.5 millions of 
users simultaneously, resulting in various and representative 
latencies for a large scale application. It is actually possible 
to use this DHT for storing arbitrary data to an also arbitrary 
address. The first paper to leverage such an open DHT is 
describing the Vanish protocol lll6ll . Interesting work has 
been achieved to parallelize PUT operations on the DHT; 
as the code of Vanish experiments is released, we re-use 
the Vanish interface to the Vuze DHT. Our prototype uses 
the latest release of Vuze (4.7.0.0). Of course, as we do not 
control code executed on remote Vuze's nodes, we can not 
impose them to implement the verification we presented in 
Section IIII-BI they only act as simple nodes implementing 
a DHT interface. 

Prototype is run on a commodity laptop (Intel Core2 Duo 
at 2.20GHz, 2.0GiB of memory), and using a basic ADSL 
Une (down/up: 18000Kbps/1200Kbps). Code is written in 
Java and cryptographic operations use the standard Java 
Security library. 

Using Vuze as a storage back-end for our protocol is 
challenging, mostly for two reasons. The first one is that 
only 512B of data can be stored by a PUT (< key, value > 
insertion). This requires us to fragment the messages and 
lists created by our protocol into chunks to store them, and 
reversely to re-aggregate those chunks when a GET opera- 
tion occurs. The second difficulty is that GET operations are 
relatively fast (order of a second), while PUT operations are 



Figure 3. A group member periodically reads and writes the wall, over 
a period of 2.5 days. A Poisson process models anival time of requests, 
with an average of one operation every 30 minutes. Operation latencies are 
reported in seconds, and c indicates the number of chunks composing the 
wall at a given time. 



prohibitively long (order of minutes) 1 3 15 1 ■ Concurrency 
is to be kept in mind as some operations need to first get 
a state in the DHT and then write a result. We chose to 
operate despite those difficulties, in order to provide a best 
effort and worst case illustration of our protocol. 

B. Scenario: joining a public group 

Basic protocol functions, described in Section IIII-CI have 
been implemented; the considered scenario is presented on 
Figure [J] It consists in creating a group, and to simulate 
arrival of join requests to it (following a Poisson process 
with an average arrival every 20 minutes). An administrator 
bot frequently retrieves group's inbox in order to always 
positively process those requests (this scenario correspond 
to joining a public group). A group member is frequently 
retrieving the list of current group members and is also 
reading/writing the group's wall (following another Poisson 
process with average 30 minutes). This scenario has been 
run continuously during 2.5 days (63 hours precisely). 

C. Protocol evaluation 

Prior to execute the scenario, we have sequentially created 
100 groups from our laptop, right after a cold start of the 
Vuze DHT locally. First 3 or 4 creations take a significantly 
longer time (2 or 3 time) than the average, measured at 16.1 
seconds per group (standard deviation: 6.2s). We re-ran the 
same group creation process, this time removing operations 
on the DHT to push data to be stored; average time drops 
to 0.66s per group. This underlines the fact that network 
operations totally dominate local structure manipulations and 
basic cryptography. 

Figure [3] shows both the time needed by a group member 
to retrieves the group's wall, and the time needed to update 
the wall by appending few bytes to it (that could correspond 



to adding a tiny URL for instance). As the 512B of allowed 
storage per insert are quickly filled by data and integrity 
information, our message chunking layer automatically splits 
and attributes locations in the DHT for the complete wall to 
be stored (first chunk still being at h{K^), while following 
ones are stored at /i(A'„,.i), with i the i"* chunk). Resulting 
time to read slightly increases, being related to the time 
needed by the slowest chunk holder to answer, and thus 
finally allowing wall to be reconstructed. Time needed to 
modify the wall is more fluctuating, as contrarily to the 
read operation (where a single answer from a chunk replica 
node is enough), Vuze waits for replication on the 19 closest 
neighbors of the target node to be complete or to time out. 
Slow or loaded nodes than slow down the PUT operation. 
Please note that we have deliberately chosen to operate in a 
worst case setting, as have left the Vuze source code totally 
intact, contrarily to paper flB!] where some modifications are 
made to the Vuze layer itself, making it possible to decrease 
storage time from minutes to few seconds. 

We now have a look at the time needed by the ad- 
ministrator to process each join request arriving in h{Ki), 
presented on Figure ID This constitutes operation of our 
protocol under an increasingly unfavorable setting: at the 
end of this experiment, 170 joins have been completed, and 
the resulting member list is split into 108 chunks (even for 
a total weight of only 54KB), as indicated by value c on 
the figure. This means that when the storage of structures 
defined in Section IIII-CI for join can be achieved in a 
single location, we observe latency in the order of a minute. 
Contrariwise, the need to split the structures due to storage 
constraints (here the member list) makes our protocol rely 
on the slowest set of node chosen to store a chunk; we then 
reach around 10 minutes at the end of the run in order to 
be able to store that list on the 108 hosts and replicas. We 
clearly observe the fact that operation time for processing 
join is tied to the number of chunks constituting the list: 
while time to write on group's wall (Figure O remains 
mostly steady, join processing time increases gradually with 
the number of chuncks (noted c on figure). A sub-linear 
factor increase is nevertheless to be noted, when considering 
this number of chunks. Without any dedicated deployment, 
simply using Vuze as in, this setting may allow a best effort 
and a background group management system to operate, 
specially when human interaction is needed to accept or 
decline requests. 

Directions for dedicated deployment and performance im- 
provements are (i) allow a larger storage for < key, value > 
than the very restrictive 512B from Vuze; this would confine 
performances to the ones on the very left of those two 
previous curves. Secondly (//), DHT operations should be 
optimized to return quickly, as proposed in Vanish im- 
plementation; this for instance includes a quick PUT of 
an operation result on the responsible node in the DHT, 
and then to leave consistency on repHca nodes occur in 



10 





tim 


3 to p 




rocess a 


oin 


C- 


50 




© 0% 


%° ° 


? 






00 




<& 






» o° 8 
o CO 








^ ° 




cP 

































28/10 28/10 29/10 29/10 29/10 29/10 30/10 30/10 30/10 30/10 31/10 31/10 
12:00 18:00 00:00 06:00 12:00 18:00 00:00 06:00 12:00 18:00 00:00 06:00 

Date 

Time 

Figure 4. Time needed by the group administrator to process join requests 
(show in minutes). Requests anive following a Poisson process with on 
average one request every 20 minutes, and are fetched by the administrator 
as soon as possible. 

background. 

VI. Related Work 

Socially-enhanced applications are currently the main 
vectors of the growth of Internet use. If means of handling 
social acquaintances are developed on an ad-hoc fashion 
by each new application, to the best of our knowledge, 
there is no generic group communication and management 
system available in a distributed setting. We believe that our 
proposal goes in the direction of genericity, reusability and 
applicability. We review main applications that take privacy 
into account. 

Diaspora [fTjl] proposes a completely distributed approach 
for Online Social Networks, in reaction to the recent privacy 
issues in Facebook. Today the project is stiU in alpha-phase 
and thus only open to a very restricted number of users. We 
could not find any scientific publication on the protocols and 
security used. 

Persona jsl proposes the use of Attribute Based Encryp- 
tion 01 to implement fine-grained access policies on shared 
content. According to the set of groups a user belongs to 
he can decrypt a given content or not. Persona supposes 
that all shared content is encrypted. Thus revocation leads 
to reencrypting all contents that were accessible by the 
concerned group. The system has no specific requirement 
on the storage service that hosts the shared data and thus 
data may be stored in a distributed manner Finally, Persona 
does not provide any specific privacy properties such as 
anonymity or unlinkability. Instead Persona targets the data 
confidentiality within a given group. 

Backes et al. jst] present a security api/cryptographic 
framework for social applications providing access control 
on shared content, privacy of social relations, secrecy of 
resources, and anonymity of users. Similar to our approach, 
users of the system can create as many pseudonyms as they 



want and use a different pseudonym for each relation with 
the other users of the system. Access control lists are build 
upon the created relations. The system uses zero knowledge 
protocols to prove the possession of a pseudonym or the 
membership of a relation. Proving a relation membership 
does not reveal the pseudonym. The system has no specific 
requirement on the storage service that hosts the shared data 
and thus data may be stored in a distributed manner The pro- 
posed system however relies on a public key infrastructure, 
which makes it difficult to scale. 

Schiavoi et al. | |23| combines gossip-based communi- 
cation protocols and onion routing to build a distributed 
and private group communication system. Groups consist 
in one or several nodes each knowing the public key of the 
group. Onion routing is used to achieve sender anonymity, 
under the hypothesis that each node published a public key. 
Whilst we consider the same threat model regarding privacy 
prop erties, we extend the model to a Dolev-Yao adversary 
1 1411 regarding security properties. In addition, we formally 
validate our security objectives against the latter attacker. We 
also address a larger set of operations, such as the creation 
of a principal and the join mechanism. Moreover we allow 
anonymous communication from any member of the group 
to any other member of the same the group. 

Finally, one may find the concept of group management 
related to publish-subscribe mechanisms in distributed sys- 
tems il ill . Such systems are typically building multicast 
trees among members for message propagation in groups. 
They differ in the sense that they are not meant to imple- 
ment complex and privacy oriented group management for 
interaction with social based applications, but instead focus 
on simple on-demand multicast. 

VII. Conclusion 

In this paper, we have shown the feasibility of distributing 
group management, in the context of a middleware empow- 
ering social-based applications. Previous works have only 
addressed parts of the distribution process. We saw that 
this distribution, as it leverages resources scattered among 
many authorities, constrains achievable security objectives. 
Yet, this paper shows that reasonable security and privacy 
properties can be reached. Our system also removes the 
control and lock of a single operator or organization on the 
group dynamic, improving state of the art in the direction 
of scalable and reusable application. 

Future work will focus on the key renewal protocol to 
support cases where the group administrator does not know 
the group members. Development or adaptation of a load 
balancing mechanism for handling popular groups is also 
to be achieved. Finally, we envision validating the privacy 
properties of our protocol formally using recent extensions 
to Scyther 
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Appendix 
HLPSL CODE 

We provide here parts of the HLPSL code used for checking security properties. The first portion of code is used for 
checking weak authentication of the entity updating a captured node. 

% Message types are coded by naturals, 10 : root 

% 11 is not a real protocol message, it is just here to ease the simulation 



role ere 

local 

init 

transition 
or . 

rc . 
ur . 

end role 



(CRE, DHT : agent, Hash : hash_func. 
State : nat , Kr : public_key 
State:- 



SND, RCV: channel (dy) ) played_by CRE def= 



State - /\ RCV(start) -|> State 
SND (Hash (Kr' ) . { 10 . .Kr' }_inv (Kr' ) } 
State - 1 /\ RCV(ll) -|> State':- 2 
State - 2 -|> State':- 3 /\ SND(Hash(Kr) 
witness (DHT, CRE, dht_cre_kr, Kr ) 



1 /\ Kr' :-new /\ 



{10.1.Kr}_inv(Kr) ) /\ 



role dht 

local 

init 

transition 
or . 
ur . 

end role 



(CRE,DHT:agent, Hash : hash_f unc, SND, RCV: channel (dy) ) played_by DHT def- 



State :nat. 
State:- 



Kr : public_key 



State - 
State - 



/\ RCV (Hash (Kr' ) . { 10 . ( 
/\ RCV (Hash (Kr) .{10.1, 



.Kr 

Kr } 



}_inv (Kr' 
_inv (Kr) ) 



) ) - I > State' :- 1 
-|> State' := 2 /\ 



/\ SND(ll) 



wrequest (DHT, CRE, dht_cre_kr , Kr ) 



role session (CRE, DHT: agent , Hash : hash_func) def- 

local SND, RCV: channel (dy) 

composition 

ere (CRE, DHT, Hash, SND, RCV) /\ dht ( CRE , DHT , Hash , SND, RCV) 

end role 

role environment () def- 

const g, d : agent , h : hash_f unc, dht_cre_kr : protocol_id 

intruder_knowledge-{g, d, h} 

composition 

session (g, d, h) 

end role 

goal weak_authentication_on _cre_kr end goal 
environment ( ) 

The second portion of code is used for proving secrecy properties, in particular the secrecy of the key Ki for all but the 
administrator and the creator. The figure [5] corresponds to a simulation of the second portion of code for creating a group 
and a principal and then forging a join request. 

% Message types are coded by naturals 

% 10:root 20:list 30: once 40: wall 50:join 60:helo 70: mess 8 : name (for directory) 90 : admin 



role ere 

local 

init 

transition 



so . 

OS . 



sa . 
as . 



pd. 

end role 



/\ 



(CRE, ADM, DHTl, CHT2 : agent , Sa : symmetric_key , Hash : hash_f unc, SND, RCV: channel (dy) ) played_by CRE def= 
State, Cr, CI, Cw: nat , Kr , Kl, Kl , Kw : publlc_key , SI, Sw: symlnetrlc_key 
State := 

Capture Root 

State = /\ RCV(start) =|> State' := 1 /\ Kr':=new() /\ Ki':=new() /\ 
SND (Hash (Kr' ) ■ ( { 10 . .Kr' .Kl' )_lnv (Kl' ) )_lnu (Kr' ) ) 
State = 1 /\ RCV(ll) =|> State' := 2 
Capture List 

state = 2 =|> State' :=3 /\ Kl':=new() /\ Sl':=new() 
secret (Kl' , secr_kl, {CRE, ADM) ) /\ 
SND (Hash (Kl' ) . { 20 . . { )_S1' .Kl' )_lnv (Kl' ) ) 
State = 3 /\ RCV(21) =|> State' := 4 
Set Once 

State = 4 =|> State' :=5 /\ SND ( { 30 . { )_lnu (Kl) }_K1 ) 
State = 5 /\ RCV(31) =|> State' :=6 
Securely send Kl SI Ki to an admin 
State = 6 =|> State' :=7 /\ SND({90. 
State = 7 /\ RCV(91) =|> State' :=8 
Publish in Directory 

State = 8 =|> State' :=9 /\ SND ( 80 . {Kr )_lnv (Kr) ) 



(assuming a dedicated channel Sa) 
.Kl.Sl.Ki)_Sa) 



role dir 

local 

init 



(CRE, DIR, PRI ragent, SND, RCV: channel (dy) ) played_by DIR def= 
State:nat, Publlshimessage 
State :=0 



transition 



rp. 

end role 



Recieve and Publish 

State - /\ RCV(80. Publish' } -|> State' :-0 /\ SND ( 81 . Publish' ) 



% this part 
role dhtl 
local 
init 

transition 
cl. 
r i . 

end role 



of the *is* under the control of the adversary 

(CRE, DHTl, DHT2 :agent, Hash : hash_f unc, SND, RCV: channel (dy) ) played_by DHTl def- 
State, Cr , Cl, Cw : nat , Kr , Ki, Kl , Kw, K j : public_key, SI, Sw : symmetric_key , Mi : message 
State:- 

Receive Once 

State - /\ RCV({30. {0}_inv(Kl) }_K1} -|> State':- /\ SND(31) 
Receive any message in Inbox 

State - /\ RCV(70.Mi') -|> State' :-0 /\ SND(70.Mi'} 



% this part 
role dht2 
local 
init 

transition 

cr . 
pr. 



cl. 

end role 



of the dht *is not* under the control of the adversary 

(CRE, DHTl, DHT2 :agent, Hash : hash_f unc, SND, RCV: channel (dy) ) played_by DHT2 def- 
State, Cr, Cl, Cw: nat , Kr, Ki, Kl, Kw, Kj :public_key, SI, Sw: symmetric_key 
State:- 

Capture Root (group) 

State - /\ RCV(Hash(Kr' ) . { {lO.O.Kr' .Ki' }_inv(Ki' ) }_inv(Kr' ) ) -|> State':- /\ SND{11} 
State - /\ SND (Hash (Kr) . { { 10 . .Kr .Ki }_inv (Ki) }_inv (Kr) ) -|> State':- /\ SND(82) 
Capture Root (principal) 

State - /\ RCV(Hash(Kr' ) . {lO.O.Kr' }_inv(Kr' ) ) -|> State':- /\ SND(ll) 
Update Root 

State - /\ RCV(Hash(Kr) . { {10.1.Kr.Ki}_inv{Ki) }_inv(Kr) ) -|> State':- 1 /\ SND(12) 
Capture List 

State - /\ RCV(Hash(Kl' ) . {20.0. {0}_S1' .Kl' }_inv(Kl' ) ) -|> State':- /\ SND{21) 



role adm 

local 

init 

transition 
cr . 

end role 



(CRE, ADM, DHTl, DHT2 : agent, Sa : symmetric_key , Hash : hash_func, SND, RCV: channel (dy) ) played_by ADM def= 
State, Cr, Cl, Cw: nat , Kr, Ki, Kl, Kw, Kj :public_key, SI, Sw : symmetric_key 
State:- 

Becomming an admin by recieving Kl SI Ki 

State - /\ RCV({90.K1' .SI' .Ki' }_Sa) -|> State':- 1 /\ SND(91) 



role pri 

local 

init 

transition 

cp. 
pc. 

rd. 



^rj . 

end role 



(PRI, DIR, DHTl, DHT2 : agent, Hash : hash_f unc, 
State, Cr : nat, Kp, K j , Kr, Ki :public_key, SI, 
State:- 



SND, RCV: channel (dy) ) played_by PRI def= 
Sw : symmet ric_key , Mi : message 



Create Principal 

State - /\ RCV(start) -|> State':-1 /\ Kp':-new() /\ SND (Hash (Kp' ) . { 10 . . Kp' }_inv (Kp' ) ) 

State - 1 /\ RCV(ll) -|> State' :-2 

Retrieve group info from the directory 

State - 2 /\ RCV (81 . {Kr' }_inv (Kr' ) ) -|> State' :-3 

Retrieve group inbox from the group root 

State - 3 /\ RCV(82) -|> RCV ( { { 1 . . Kr ' . Ki ' }_inv (Ki ' ) }_inv (Kr ' ) ) /\ State':-4 

Request Join 

State - 4 /\ Kj' :-new() /\ SND ( { { { 60 . Kp . K j 



role session (CRE, ADM, DHTl , DHT2, DIR, PRI : agent, Sa : symmet ric_key, Hash : hash_func) def- 

local SND, RCV: channel (dy) 

composition 

ere (CRE, ADM, DHTl, DHT2, Sa, Hash, SND, RCV) /\ 
adm (CRE, ADM, DHTl, DHT2, Sa, Hash, SND, RCV) /\ 
dhtl (CRE, DHTl, DHT2, Hash, SND, RCV) /\ 
dht 2 (CRE, DHTl, DHT2, Hash, SND, RCV) /\ 
dir (CRE, DIR, PRI, SND, RCV) /\ 
pri (PRI, DIR, DHTl, DHT2, Hash, SND, RCV) 

end role 

role environment () def- 

const g, a, dl , d2 , di , p : agent , sa : symmet ric_key, h : hash_f unc, secr_kl : protocol_id 

int ruder_knowledge- { g, a, dl , d2 , di , p, h } 

composition 

session (g, a, dl , d2 , di , p, sa, h) 

end role 

goal secrecy_of secr_kl end goal 



environment ( ) 



Trace Files Modes Variables monitoring 
< Previous step Next step > r Untype 



Jncoming events : 



(dir, 6) -> (lntruder_, 0) : S1 .Publish 
(dir, 6)-> (pri, 7) : 81. Publish 



Past events : 



^|(dht. 5) -> (ere, 3) : 11 
kcre, 3) -> (dht, 5) : Hash(KI).{20.Q.{0}_SI.KI}_inv(KI) 
|(dht, 5)-> (ere. 3) : 21 



(ere, 3) -> (dht, 5) : {30.{0}_inv(KI))_KI 



|(dht, 5) -> (ere, 3) : 31 



Intruder knowledge : 



Compose knowledge 



a 

dh 
di 
P 

iiJ_ 



Intrui 
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Figure 5. Simulation of the second portion of code, wittiin the AVISPA + SPAN framework. 



